A former NASA administrator says he is "encouraged" that the US Congress is considering legislation to prevent NASA from spending more than 50 percent of its launch funding on any single provider.

"America succeeds in space when American companies compete, innovate, and grow," former NASA Administrator Jim Bridenstine wrote on LinkedIn. "I’m encouraged to see Congress taking meaningful steps to strengthen the industrial base that underpins both our civil and national security space missions."

Bridenstine commended the chairman of the Senate Committee on Commerce, Science, and Transportation, Sen. Ted Cruz (R-Texas), and ranking member Maria Cantwell (D-Wash.) on a new provision that appears in the NASA Transition Authorization Act of 2025. Cruz plans to hold a markup hearing for the legislation on Wednesday.

"Congress is reinforcing competition and protecting the small and medium-sized manufacturers, propulsion companies, avionics developers, and suppliers that make up the backbone of America’s space enterprise," Bridenstine wrote. "Competition lowers costs, accelerates innovation and provides redundancy."

The provision appears to target SpaceX, which currently launches the only crewed vehicle capable of reaching the space station, Dragon; both US cargo vehicles (Dragon and Cygnus); as well as a majority of NASA's science missions. If passed into law, this language could effectively prohibit SpaceX from launching crewed lunar missions from Earth on Dragon or Starship for NASA in addition to its existing portfolio.

Lucrative lobbying

What Bridenstine did not say on social media is that his consulting firm, The Artemis Group, netted $990,000 from United Launch Alliance in 2025, according to public records. This was nearly a third of all revenue raised by his lobbying last year, a total of $3,385,000. United Launch Alliance was formerly a major competitor to SpaceX in the US launch industry.

The Senate's provision targets launch revenues but excludes space transportation services (such as the human landers being developed by SpaceX and Blue Origin).

Another former NASA official, Phil McAlister, replied to Bridenstine's post that it was "disappointing" to see him attach his name to the provision. Instead of promoting competition, McAlister said the new language is actually anti-competitive.

"What it supports is using the political process to funnel money to favored companies with inferior products," said McAlister, who directed commercial space at NASA from 2005 to 2024. "Competition is a full and open match between companies where the best company wins. If this legislation passes as is, it ensures that the best company will not win. Instead the second or third place company will get an award because they could not compete and win fairly. And the country will see that superior performance does not win, having the best lobbyist does."

McAlister and other critics of the provision say no one wants a launch monopoly and that NASA has in fact sought to on-ramp new providers through programs such as its venture class services program that allocates payloads to riskier providers. However, they note, as United Launch Alliance has struggled to bring its Vulcan rocket online over the past five years, SpaceX has stepped up to keep the International Space Station flying and launch critical missions like NASA's $4 billion Europa Clipper spacecraft.

Ironically, United Launch Alliance held a US launch monopoly earlier this century before SpaceX came along and disrupted its business with lower-cost, more frequent access to space. Now United Launch Alliance must compete not only with SpaceX but a newer generation of more nimble companies building reusable rockets, including Blue Origin, Rocket Lab, Relativity Space, Firefly, and Stoke Space. NASA has made it clear to these companies that it is eager to buy launch services at competitive prices from them.

A highly regarded administrator

A former Republican House member from Oklahoma, Bridenstine served a generally well-regarded term as NASA administrator from April 2018 to January 2021 during President Trump's first term.

The high point of his tenure in office came in May 2020, thanks to SpaceX. That summer, with the Crew Dragon vehicle, SpaceX and NASA successfully flew two astronauts to the International Space Station, breaking America's dependence on Russia for low-Earth orbit transportation. Bridenstine relished this with an oft-repeated mantra of launching American astronauts on American rockets from American soil.

However, after leaving NASA, Bridenstine has appeared to become hostile to the dominant company founded by Elon Musk. He joined the board of a competitor, Viasat. Later Bridenstine became the executive of Government Operations for United Launch Alliance, in addition to his firm collecting a hefty lobbying fee.

All of this is not particularly abnormal for the revolving door in Washington, DC, where senior officials go between government positions and industry. Nevertheless some observers were surprised by the striking nature in which Bridenstine attacked NASA for the decision to award a Human Landing System contract to SpaceX in April 2021, three months after he left office. A new administrator had not yet been confirmed at NASA at the time, so a senior NASA engineer, Steve Jurczyk, served as acting administrator for the space agency.

Attacking his own process

Bridenstine sharply criticized this lander decision during testimony before Cruz's committee last September.

"There was a moment in time when we had no NASA administrator," he said at 42 minutes into the hearing. "It was after I was gone, and before Senator Nelson became the NASA administrator. An architecture was selected. And I don't know how this happens, but the biggest decision in the history of NASA, at least since I've been paying attention, the biggest decision happened in the absence of a NASA administrator. And that decision was, instead of buying a Moon lander, we're gonna buy a big rocket."

He was referring to Starship, and the plan to use the vehicle as a lunar lander.

Almost everyone in the space industry agrees that Starship offers a cumbersome solution to get two humans to the lunar surface, especially if the goal is to do so as quickly as possible rather than building a sustainable transportation system over time. However, Bridenstine's criticism of its selection process omitted some key facts.

He, himself, oversaw the initial selection of Starship as one of three options for a lunar lander in April 2020. He made the appointment of Kathy Lueders as head of human exploration in June 2020, knowing she would be the source selection official for the lunar lander contract. And Lueders ended up selecting the one company with a proposal that fit within the NASA budget allocation for a lunar lander that Bridenstine had obtained from Congress.

The reality is that Bridenstine was the architect of the Artemis program, he obtained its budget from Congress, he wanted the human lander to be a commercial partnership, and the team he put in place made the final decision. The implication that Jurczyk was effectively not a real administrator capable of making the right decisions is unfortunate, as Jurczyk is not alive to defend himself. He died of pancreatic cancer in 2023.

However, Bridenstine's comments are in line with criticism of NASA leadership in 2021 by United Launch Alliance, which characterized it as "incompetent and unpredictable" in leaked emails.

Read full article

Comments

"Advanced AI models appear willing to deploy nuclear weapons without the same reservations humans have when put into simulated geopolitical crises," reports New Scientist: Kenneth Payne at King's College London set three leading large language models — GPT-5.2, Claude Sonnet 4 and Gemini 3 Flash — against each other in simulated war games. The scenarios involved intense international standoffs, including border disputes, competition for scarce resources and existential threats to regime survival. The AIs were given an escalation ladder, allowing them to choose actions ranging from diplomatic protests and complete surrender to full strategic nuclear war... In 95 per cent of the simulated games, at least one tactical nuclear weapon was deployed by the AI models. "The nuclear taboo doesn't seem to be as powerful for machines [as] for humans," says Payne. What's more, no model ever chose to fully accommodate an opponent or surrender, regardless of how badly they were losing. At best, the models opted to temporarily reduce their level of violence. They also made mistakes in the fog of war: accidents happened in 86 per cent of the conflicts, with an action escalating higher than the AI intended to, based on its reasoning... OpenAI, Anthropic and Google, the companies behind the three AI models used in this study, didn't respond to New Scientist's request for comment. The article includes this comment from Tong Zhao, a senior fellow in the Nuclear Policy Program at the Carnegie Endowment for Peace think tank. "It is possible the issue goes beyond the absence of emotion. More fundamentally, AI models may not understand 'stakes' as humans perceive them." Thanks to long-time Slashdot reader Tufriast for sharing the article.

Read more of this story at Slashdot.

Southern California's air quality board rejected proposed rules to phase out gas-powered appliances after receiving more than 20,000 opposition comments generated through CiviClick, "the first and best AI-powered grassroots advocacy platform." Phys.org reports: A Southern California-based public affairs consultant, Matt Klink, has taken credit for using CiviClick to wage the opposition campaign, including in a sponsored article on the website Campaigns and Elections. The campaign "left the staff of the Southern California Air Quality Management District (SCAQMD) reeling," the article says. It is not clear how AI was deployed in the campaign, and officials at CiviClick did not respond to repeated requests for comment. But their website boasts several tools, including "state of the art technology and artificial intelligence message assistance" that can be used to create custom advocacy letters, as opposed to repetitive form letters or petitions often used in similar campaigns. When staffers at the air district reached out to a small sample of people to verify their comments, at least three said they had not written to the agency and were not aware of any such messages, records show. But the email onslaught almost certainly influenced the board's June decision, according to agency insiders, who noted that the number of public comments typically submitted on agenda items can be counted on one hand. The proposed rules were nearly two years in the making and would have placed a fee on natural gas-powered water heaters and furnaces, favoring electric ones, in an effort to reduce air pollution in the district, which includes Orange County and large swaths of Los Angeles, Riverside and San Bernardino counties. Gas appliances emit nitrogen oxides, or NOx -- key pollutants for forming smog. The implications are troubling, experts said, and go beyond the use of natural gas furnaces and heaters in the second-largest metropolitan area in the country.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Wired: OpenAI has fired an employee following an investigation into their activity on prediction market platforms including Polymarket, WIRED has learned. OpenAI CEO of Applications, Fidji Simo, disclosed the termination in an internal message to employees earlier this year. The employee, she said, "used confidential OpenAI information in connection with external prediction markets (e.g. Polymarket)." "Our policies prohibit employees from using confidential OpenAI information for personal gain, including in prediction markets," says spokesperson Kayla Wood. OpenAI has not revealed the name of the employee or the specifics of their trades. Evidence suggests that this was not an isolated event. Polymarket runs on the Polygon blockchain network, so its trading ledger is pseudonymous but traceable. According to an analysis by the financial data platform Unusual Whales, there have been clusters of activities, which the service flagged as suspicious, around OpenAI-themed events since March 2023. Unusual Whales flagged 77 positions in 60 wallet addresses as suspected insider trades, looking at the age of the account, trading history, and significance of investment, among other factors. Suspicious trades hinged on the release dates of products like Sora, GPT-5, and the ChatGPT Browser, as well as CEO Sam Altman's employment status. In November 2023, two days after Altman was dramatically ousted from the company, a new wallet placed a significant bet that he would return, netting over $16,000 in profits. The account never placed another bet. The behavior fits into patterns typical of insider trades. "The tell is the clustering. In the 40 hours before OpenAI launched its browser, 13 brand-new wallets with zero trading history appeared on the site for the first time to collectively bet $309,486 on the right outcome," says Unusual Whales CEO Matt Saincome. "When you see that many fresh wallets making the same bet at the same time, it raises a real question about whether the secret is getting out." [...] Though this is the first confirmed case of a large technology company firing an employee over trades in prediction markets, it's almost certainly not the last. Opportunities for tech sector employees to make trades on markets abound. "The data tells me this is happening all over the place," Saincome says.

Read more of this story at Slashdot.

Last time, we used a MSGF_DIALOG­BOX message filter to hook into the Is­Dialog­Message so that we had the option to grab the ESC before it gets turned into an IDCANCEL. There are some problems with our initial foray.

One is the problem of recursive dialogs. If the first dialog shows another copy of itself (for example, a certificate dialog showing a dialog for its parent certificate), then the thread-local variable gets overwritten, and the first dialog’s information is lost.

We could solve that by having each dialog remember the original value and restore it when the dialog dismisses. Alternatively, we could maintain an explicit stack of dialogs, pushing when a new dialog is created and popping when it is destroyed.

However, this fails to handle the case where the dialog is modeless. In that case, the two dialogs could be running concurrently rather than recursively. Instead of a stack, we really need a per-thread set of active dialogs.

Another thing to worry about is that if this code is put into a static library, and two components in the same thread both use that static library, then you have to be careful that the two copies of the library don’t conflict with each other.

I came up with this initial idea:

#define DIALOG_WANTS_ESC_PROP TEXT("DialogWantsEsc")

LRESULT CALLBACK DialogEscHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
    if (nCode == MSGF_DIALOGBOX) {
        auto msg = (MSG*)lParam;
        if (msg->message == WM_KEYDOWN &&
            msg->wParam == VK_ESCAPE) {
            auto hdlg = GetAncestor(msg->hwnd, GA_ROOT);
            auto customMessage = PtrToUint(GetProp(hdlg,
                                           DIALOG_WANTS_ESC_PROP));
            if (customMessage &&
                !(SendMessage(msg->hwnd, WM_GETDLGCODE,
                             msg->wParam, lParam) &
                         (DLGC_WANTALLKEYS | DLGC_WANTMESSAGE))) {
                return SendMessage(hdlg, customMessage, 0, lParam);
            }
        }
    }
    return CallNextHookEx(nullptr, nCode, wParam, lParam);
}

The idea here is that instead of having to manage a table of per-thread registrations, we just let dialogs self-register by setting the DIALOG_WANTS_ESC_PROP property to the message number they want to receive when the user presses ESC.

If there are two copies of this hook installed, then the Dialog­Esc­Hook­Proc is called twice. The first one sends the custom message and gets the dialog’s response, and returns it; it never passes the message down the hook chain. Therefore, the second and subsequent hooks never get to run, so we don’t have a problem of the custom message getting sent multiple times for the same call to Is­Dialog­Message.

This design has the advantage that multiple DLLs using this pattern can coexist because the first hook (whichever it is) does all the work for everybody.

An alternate, more complex, design would pass the call down the chain if the dialog box declined to handle the ESC key, in case some other hook wanted to do something special. The catch is that if there are multiple copies of this hook installed, each one will send the custom message to the dialog, which would be bad if the handler for the custom message had side effects like showing a confirmation dialog.

So we can add the rule that the custom message must be safe to call multiple times if it returns FALSE. This means that if it wants to display a confirmation dialog, it should always return TRUE even if the user cancels.

LRESULT CALLBACK DialogEscHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
    if (code == MSGF_DIALOGBOX) {
        auto msg = (MSG*)lParam;
        if (msg->message == WM_KEYDOWN &&
            msg->wParam == VK_ESCAPE) {
            auto hdlg = GetAncestor(msg->hwnd, GA_ROOT);
            auto customMessage = PtrToUInt(GetProp(hdlg,
                                           DIALOG_WANTS_ESC_PROP));
            if (customMessage &&
                !(SendMessage(msg->hwnd, WM_GETDLGCODE,
                             msg->wParam, msg) &
                         (DLGC_WANTALLKEYS | DLGC_WANTMESSAGE)) &&
                 SendMessage(hdlg, customMessage, 0, lParam)) {
                 return TRUE;                                  
            }
        }
    }
    return CallNextHookEx(nullptr, nCode, wParam, lParam);
}

Or we can have the first hook leave a note for the other hooks that the message has already been handled and that they shouldn’t try to handle it again.

#define DIALOG_WANTS_ESC_PROP TEXT("DialogWantsEsc")
#define CURRENT_MESSAGE_PROP TEXT("DialogWantsEscCurrentMessage")

LRESULT CALLBACK DialogEscHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
    if (code == MSGF_DIALOGBOX) {
        auto msg = (MSG*)lParam;
        if (msg->message == WM_KEYDOWN &&
            msg->wParam == VK_ESCAPE) {
            auto hdlg = GetAncestor(msg->hwnd, GA_ROOT);
            auto customMessage = PtrToUInt(GetProp(hdlg,
                                           DIALOG_WANTS_ESC_PROP));
            if (customMessage) {
                auto previous = GetProp(hdlg, CURRENT_MESSAGE_PROP);
                if (previous != msg &&                              
                    !(SendMessage(msg->hwnd, WM_GETDLGCODE,
                                 msg->wParam, msg) &
                             (DLGC_WANTALLKEYS | DLGC_WANTMESSAGE))) {
                    return SendMessage(hdlg, customMessage, 0, lParam);
                }
                SetProp(hdlg, CURRENT_MESSAGE_PROP, msg);                     
                auto result = CallNextHookEx(nullptr, nCode, wParam, lParam); 
                SetProp(hdlg, CURRENT_MESSAGE_PROP, previous);                
                return result;                                                
            }
        }
    }
    return CallNextHookEx(nullptr, nCode, wParam, lParam);
}

The first hook will send the message to the dialog. and if the dialog declines to handle it, it passes the messages to the other hooks, but setes the “current message” property to the message that was already handled, so that other hooks won’t try to handle it again.

The last part of the puzzle is installing the hook. Since we are assuming that we cannot alter the dialog loop, the hook has to be installed by the dialog itself.

Let’s assume that this dialog box already allocates other dialog state, so we can add the hook handle to the state structure.

struct DIALOGSTATE
{
    wil::unique_hhook escapeHook;
    ⟦ other stuff ⟧
};

// each dialog can choose its own custom message
#define DM_ESCPRESSED (WM_USER+1000)

INT_PTR CALLBACK DialogProc(HWND hdlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message) {
    case WM_INITDIALOG:
        {
            DIALOGSTATE* state = new(std:nothrow) DIALOGSTATE();
            if (!state) { EndDialog(hdlg, -1); return FALSE; }
            SetWindowLongPtr(hdlg, DWLP_USER, (LONG_PTR)state);
            state->escapeHook.reset(SetWindowsHookEx(WM_MSGFILTER,     
                             DialogEscHookProc,                        
                             nullptr, GetCurrentThreadId()));          
            SetProp(hdlg, DIALOG_WANTS_ESC_PROP,                       
                    IntToPtr(DM_ESCPRESSED));                          
            ⟦ other dialog initialization as before ⟧
            ⟦ ending with "return (whatever)" ⟧
        }

    case DM_ESCPRESSED:
        if (⟦ we want to process the ESC key ourselves ⟧) {
            ⟦ do custom ESC key processing ⟧
            SetWindowLongPtr(hdlg, DWLP_MSGRESULT, TRUE);
            return TRUE;
        }
        break;

    case WM_DESTROY:
        {
            auto state = (DLGSTATE*)GetWindowLongPtr(hdlg, DWLP_USER);
            delete state;
        }
        break;

    ⟦ handle other messages ⟧
    }
    return FALSE;
}

The dialog installs the hook when it is created and removes it when it is destroyed. The hook has become an implementation detail of the dialog.

Now, I don’t recommend doing all this. Better is to just treat with the ESC like any other press of the (possibly imaginary) Cancel button. One of the few scenarios I can think of where this could be useful is if you want to display an extra confimation for the Close button (since its meaning is potentially ambiguous). This is still nonstandard, but at least it’s not too nonstandard. And for that, you can just intercept WM_CLOSE instead of trying to intercept the ESC. Intercepting the ESC was really just an excuse to show off message filters, which tend to be unappreciated.

The post Intercepting messages inside <CODE>Is­Dialog­Message</CODE>, fine-tuning the message filter appeared first on The Old New Thing.

An anonymous reader shares a column: I'm going to take the diplomatic hat off here and say with brutal honesty: basically everybody in the music business hates Spotify except for the people who work there. It's a platform that sucks artists for everything they have, it actively prevents community building, and, despite all of that, the platform still struggles to maintain a healthy profit margin. The streaming business model is fundamentally broken. And eventually, its demise will become more and more obvious to recognize. I'll break down exactly why the DSP era is coming to a grinding halt, why the major labels are quietly terrified, and why the artists who don't pivot now are going to go down with the ship. [...] Jimmy Iovine put it bluntly: "The streaming services have a bad situation, there's no margins, they're not making any money." This model only works for Apple, Amazon, and Google, because they don't need their music platforms to be wildly profitable. Amazon uses music as a loss-leader to keep you paying for Prime. Apple uses it to sell $1,000 iPhones. As for Spotify, or any standalone music streaming company, they're kind of screwed. And guess what -- when the platform's margins are structurally squeezed, guess who gets squeezed first? The artists. [...] What if Jimmy is right? If the DSPs are "minutes away from obsolete," what replaces them? Well, I'm not sure the DSPs are going to disappear overnight, but if you're an artist or a manager trying to sustain yourself in this evolving music economy, the answer is direct ownership. The artists who will survive the next five years are the ones who are quietly shifting their focus away from the "ATM Machine." They are building their own cultural hangars. They are capturing phone numbers on Laylo. They are driving fans to private Discord servers. They are focusing on ARPF (Average Revenue Per Fan) through high-margin merch, vinyl, and hard tickets, rather than begging for fractions of a penny from a playlist placement. We are witnessing the death of the "Mass Audience" and the birth of the "Micro-Community."

Read more of this story at Slashdot.